1. Field of the Invention
The present invention relates to computer software, and deals more particularly with techniques for achieving context-sensitive confidentiality within a federated environment for which content is aggregated in a distributed Web portal (or similar aggregation framework).
2. Description of the Related Art
Web portals (sometimes referred to equivalently as portal platforms, portal systems, or portal servers) are designed to serve as a gateway, or focal point, for access to an aggregation or collection of information and applications from many different sources. Portals often provide an end user view, commonly referred to as a “portal page”. A portal page is often structured as a single overview-style page (which may provide links for the user to navigate to more detailed information). Alternatively, portal pages may be designed using a notebook paradigm whereby multiple pages are available to the user upon selecting a tab for that page. (Other frameworks which aggregate content and/or services may have characteristics analogous to those of a portal. The term “portal”, as used herein, is intended to include such other aggregation frameworks.)
In addition to providing for content delivery to end users, Web portals are increasingly used as gateways to so-called “Web services” (i.e., network-accessible services) for distributed computing. Web services are a rapidly emerging technology for distributed application integration in a distributing computing environment such as the Internet. In general, a “Web service” is an interface that describes a collection of network-accessible operations. Web services fulfill a specific task or a set of tasks, and may work with one or more other Web services in an interoperable manner to carry out their part of a complex workflow or a business transaction. For example, completing a complex purchase order transaction may require automated interaction between an order placement service (i.e., order placement software) at the ordering business and an order fulfillment service at one or more of its business partners.
With Web services, distributed network access to software becomes widely available for program-to-program operation, without requiring intervention from humans. Web services are generally structured using a model in which an enterprise providing network-accessible services publishes the services to a network-accessible registry, and other enterprises needing services (or human beings searching for network-accessible services) are able to query the registry to learn of the services' availability. (Hereinafter, references to an entity or user making use of Web services are intended to include programmatic entities as well as human beings.) The participants in this computing model are commonly referred to as (1) service providers, (2) service requesters, and (3) service brokers. These participants, and the fundamental operations involved with exchanging messages between them, are illustrated in FIG. 1. The service providers 100 are the entities having services available, and the registry to which these services are published 110 is maintained by a service broker 120. The service requesters 150 are the entities needing services and querying 140 the service broker's registry. When a desired service is found using the registry, the service requester binds 130 to the located service provider in order to use the service. These operations are designed to occur programmatically, without requiring human intervention, such that a service requester can search for a particular service and make use of that service dynamically, at run-time. The Web services model is theoretically available for any type of computing application.
Web services allow applications and services (referred to hereinafter as services for ease of reference) to interact with one another using Web-based standards. A number of standards are being promulgated in the Web services arena as the problems inherent in that environment become better understood. A complete discussion of these protocols is beyond the scope of the present discussion, but basic protocols on which Web services work is being built include HTTP (“Hypertext Transfer Protocol”), SOAP (“Simple Object Access Protocol”), and WSDL (“Web Services Description Language”). HTTP is commonly used to exchange messages over TCP/IP (“Transmission Control Protocol/Internet Protocol”) networks such as the Internet. SOAP is an XML (“Extensible Markup Language”) based protocol used to send messages for invoking methods in a distributed environment. WSDL is an XML format for describing distributed network services.
For more information on SOAP, refer to “Simple Object Access Protocol (SOAP) 1.1, W3C Note 08 May 2000”, which is available from the World Wide Web Consortium, or “W3C”. The WSDL specification is titled “Web Services Description Language (WSDL) 1.1, W3C Note 15 Mar. 2001”, and is also available from the W3C. HTTP is described in Request For Comments (“RFC”) 2616 from the Internet Engineering Task Force, titled “Hypertext Transfer Protocol—HTTP/1.1” (June 1999). It should be noted that references herein to “HTTP” are intended in a generic sense to refer to HTTP-like functions. Some Web services operations, for example, require HTTPS instead of HTTP, where HTTPS is a security-enhanced version of HTTP.
The goal of Web services is to provide service requesters with transparent access to program components which may reside in one or more remote locations, even though those components might run on different operating systems and/or be written in different programming languages than those of the requester.
A federation within a Web services context relates to collaboration among loosely-coupled and complementary Web services across security domains. For example, suppose employees from two companies would like to meet with one another, and that the two companies have different automated calendar/meeting services, each of which provides complementary functionality (e.g., by managing employee's schedules). Federating these complementary services would allow the independent calendar services to exchange application information, enabling the employees to establish the joint meeting using their respective calendar services.
While support for Web services and portals in federated environments continues to make great progress, areas remain where improvements can be made.